Location-to-Service Translation (LoST) protocol provides a request-response protocol for mapping a given location to a service identifier, and is described in “LoST: A Location-to-Service Translation Protocol,” Request for Comment (RFC) 5222 (August 2008), the subject matter of which is hereby incorporated by reference. Generally, the LoST protocol is an XML-based protocol for mapping location information and service identifiers to service contact uniform resource identifiers (URIs) and domain names corresponding to LoST services. The service contact URIs and domain names enable a requesting user device or client to contact the entity providing the LoST service. For example, the LoST protocol may be used to identify a Public Safety Answering Point (PSAP) having jurisdiction over a client based on predetermined boundaries serviced by the PSAP and the location of the client when a request for emergency assistance is made.
The LoST protocol describes a mechanism for deployment of a network of LoST servers, which are configured to forward a request or query from an originating client (e.g., user device) through a “forest structure” of LoST servers. The query is ultimately directed to an appropriate authoritative LoST server, which is the LoST server capable of answering or resolving the client's request. The network of LoST servers may operate recursively or iteratively, on a request-by-request basis. In recursive mode, each LoST server initiates a query on behalf of a previous requester, and returns the result of the query to the previous requester in a corresponding response message. For example, each LoST server may initiate a new query message in response to an initial query message from the original client until the appropriate authoritative LoST server is contacted. In iterative mode, each LoST server returns a redirection response message to the client, indicating the identity of the next LoST server to be queried (if the current LoST server cannot resolve the initial query), until the authoritative LoST server is ultimately identified and queried by the client.
FIG. 1 is a simplified block diagram illustrating a conventional LoST protocol network, showing an example deployment implementing the recursive mode.
Referring to FIG. 1, LoST protocol network 100 includes a forest structure of LoST servers 121-123 and authoritative LoST servers 131-132. In the depicted example, user device 110 accesses authoritative LoST server 131 through sequential queries by intervening LoST servers 121 and 123 of the LoST protocol network 100, in response to an initial query from the user device 110, as indicated by the arrows. More particularly, the user device 110 (acting as a client) sends a query message containing location information and a service identifier, e.g., encoded as a Uniform Resource Name (URN), to servicing LoST server 121. The LoST server 121 attempts to map the location information and the service identifier to one or more URIs in a database. If the LoST server 121 is unable to resolve the query message (as is the case shown in FIG. 1), the LoST server 121 sends a query message to LoST server 123 (now acting as a client), including the location information and the service identifier.
The LoST server 123 similarly attempts to map the location information and the service identifier to one or more URIs in its database, and if it is unable to resolve the query message (as is the case shown in FIG. 1), the LoST server 123 sends a query message to authoritative LoST server 131, including the location information and the service identifier. By definition, the authoritative LoST server 131 acts only as a server (as opposed to sometimes acting as a client), and is able to successfully resolve the location information and the service identifier to a URI or set of URIs. An appropriate response message is returned to the client 110 along a reverse path through the LoST servers 121 and 123.
Along the forward routing path, each LoST network node populates a “path element” included in the query messages with an identifying “via element,” which may be a corresponding URN, for example. In other words, each of the user device 110, the LoST servers 121 and 123, and the authoritative LoST server 131 adds a via element to the path element identifying itself on the forward path. The path element is not modified on the reverse routing path, although the path element is included in the response messages, enabling the LoST network nodes to follow the reverse order of the via elements. The path element thereby prevents loops and allows tracing of query and response paths.
The conventional approach described above ties up resources and is otherwise time consuming, which may be particularly problematic in emergency situations. Each LoST server in the chain must check its database for mapping purposes, and launch a query to the next LoST server identified.
Accordingly, in a representative embodiment, a method implemented by a proxy server is provided for routing requests for a Location-to-Service Translation (LoST) service without traversing a forest node structure. The method includes receiving a request for the LoST service initiated by a client, the request including a location of a user device and a requested service; identifying an authoritative LoST server configured to service the requested service and bounded by a service boundary that includes the location included in the request; and directly forwarding the request to the identified authoritative LoST server, without routing through any other LoST server.
In another representative embodiment, a method implemented by a proxy server is provided for directly routing requests for a LoST service. The method includes receiving a LoST query message initiated by a client, the LoST query message including an identifier of a requested LoST service, a location of a user device requesting the requested LoST service, and a client identifier corresponding to the client; identifying an authoritative LoST server configured to service the requested LoST service for the location of the user device; modifying the LoST query message to replace the client identifier with a proxy identifier corresponding to the proxy server; and directly forwarding the modified LoST query message to the identified authoritative LoST server.
In yet another representative embodiment, a computer readable medium storing code, executable by a computer processor in a proxy server, is provided for routing requests for a LoST service without traversing a forest node structure. The computer readable medium includes receiving code for receiving a request for the LoST service initiated by a client, the request including a location of a user device and a requested service; identifying code for identifying an authoritative LoST server configured to service the requested service and bounded by a service boundary that includes the location included in the request; and routing code for directly forwarding the request to the identified authoritative LoST server, without routing through any other LoST server.